home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-penners-mobileip-smip-00.txt
< prev
next >
Wrap
Text File
|
1993-10-01
|
35KB
|
1,377 lines
- 1 -
Internet Engineering Task Force John Penners
INTERNET DRAFT U S WEST Advanced Technologies
draft-penners-mobileip-smip-00.txt Yakov Rekhter
T.J. Watson Research Center, IBM Corp.
September 1993
Simple Mobile IP (SMIP)
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
"This document has been presented to, and is being evaluated by, the
"Mobile IP" working group of the IETF. This document is being
published as an Internet Draft in order to allow the general IETF
community the opportunity to gain a wider understanding of the issues
involved in mobile IP routing, as well as to understand the specific
solution proposed in this document. This document has not received
any formal endorsement from the Mobile IP working group.
1 Introduction
There have been several proposals for supporting mobility at the
network layer (e.g. [1], [2], [3], [4], [5]). While all these
proposals differ from each other in a number of features, all of them
also exhibit certain commonalities with each other. The proposal
described in this document is an attempt to extract and exploit this
commonality. Its goal is to provide a simple, but solid foundation
Expiration Date March 1994 [Page 1]
- 2 -
upon which additional optional features can be introduced in a
backward compatible fashion. The simplicity of the proposed scheme is
also expected to positively impact manageability and security aspects
associated with supporting mobility.
It is our premise that the following factors will be key to
widespread usage:
1. Adequate Security - Customers are not going to use Mobile-IP
(portable) if it does not provide adequate security protection.
These include masquarading as the mobile host, unwilling
disclosure of MH location, and potentially privacy.
2. Ability to run traditional applications - It is not clear how
well existing transport protocols will deal with transients
introduced by mobility. We also don't know many aspects
associated with mobility (e.g. its dynamics). Therefore, it is
likely that some of the problems would not be discovered until
the actual deployment and usage. Likewise, what may be
perceived as a problem today, may turned out to be a non-
problem in the operational environment.
3. Manageability - The mobile system must be easy to manage or
system administrators won't want to deploy them.
4. Rapid Wide Spread Deployment - Systems are more likely to be
deployed if there is already an established base. This argues
for simple, easy to install and manage systems.
5. Mobility - It is quite possible that most of the requirements
in today's environment can be satisfied with portability. In
the long term, on-line mobility may not be sufficient -- off-
line mobility may be required. However, it is unlikely that
the off-line mobility can be solved at the network layer.
2 Elements
The scheme is described in terms of four components, Stationary Host
(SH), Mobile Host (MH), Home Register (MR), and Visiting Register
(VR). The VR and HR could be colocated within a single physical
entity which may or may not have traditional router functionality.
Expiration Date March 1994 [Page 2]
- 3 -
- Stationary Host (SH) : This is a host that may or may not be
stationary but is viewed as stationary.
- Home Register (HR) : This machine acts as an agent for the
Mobile Host. It keeps track of its location and provide a
service that relays the incoming message to the Mobile Host.
- Visiting Register (VR) : This machine provides the Care-of
service for the Mobile Host. It issues a c/o address to the
mobile host and receives message from the MH's HR and forwards
them to the MH.
- Mobile Host (MH) : This is the mobile host. It requires some
new protocols to handle it's mobility. All communication to
this host (but not from this host) is through the Home Register
(HR) of the Mobile Host (MH).
3 Data and Control Flows
There are only three flows - two are data and one is a control
The two data flows are as follows:
(1) SH to MH => SH -> HR -> VR -> MH
(2) MH to SH => MH -> VR -> SH
The proposal doesn't preclude future data traffic flow from SH to MH
that would bypass the HR.
Expiration Date March 1994 [Page 3]
- 4 -
The only control flow which originates and terminates at the MH is as
follows:
MH VR HR
| | |
| MH Hello | |
|------------------------->| Location Update Request |
| |---------------------------->|
| | |
| | Location Update Confirm |
| |<----------------------------|
| VR Confirm | |
|<-------------------------| |
Since this model has four elements the following matrix can be used
to illustrate the information content that flow between elements.
This matrix contains both data and control flows.
\ Receiver
\ MH VR HR SH |
Sender |-------|-------|-------|-------|
MH | N/A | 1 | 2 | 3 |
|-------|-------|-------|-------|
VR | 4 | OP | 5 | OP |
|-------|-------|-------|-------|
HR | 6 | 7 | N/A | 8 |
|-------|-------|-------|-------|
SH | 10 | OP | 9 | N/A |
|-------|-------|-------|-------|
OP - could be an option. They increase the complexity of the
protocol and are not discussed in this proposal.
VR -> VR could be used if there was handoff between VRs. This could
create a security problem.
N/A - Not applicable
The content of new packets is indicated with [ ] below. We assume
that the link layer will contain both the destination and source
physical addresses.
Expiration Date March 1994 [Page 4]
- 5 -
1) MH -> VR
- Notify VR and acquire c/o Address
- Provide MH's permanent address to VR
- Provide authentication for VR to pass to HR
[ VR IP Addr, HR IP Addr, Sequence, MH/HR specific data (auth)]
MH/HR specific data and interpretation by the VR is not required. It
is likely to contain auth key and time stamp.
2) MH -> HR This is an indirect flow of information (through the VR)
- Authentication and location info transmitted via VR
Info contained in MH -> VR data packet
3) MH -> SH
- Data via straight path (but flows through the VR serving the
MH)
Info contained in normal IP packet
4) VR -> MH
- Provide or refuse c/o on request
- Forward received messages to MH
- Notify MH of HR refusal to serve
[MH addr, VR addr, Sequence, Attachment Accepted or Refused]
5) VR -> HR
Expiration Date March 1994 [Page 5]
- 6 -
- Confirm MH location (possible after authentication)
- Delivery Status (i.e. unable to deliver message)
- Participate in tunnel Setup and teardown (detailed mgmt
provided by tunneling mechanism)
[ HR IP Addr, VR IP Addr, MH IP Addr, Sequence, MH/HR specific data]
6) HR -> MH
This is an indirect flow (passes through VR)
- Forward Data packets
Provided via HR -> VR
7) HR -> VR
- Tunnelled data
- Participate in tunnel Setup and teardown (detailed mgmt
provided by tunneling mechanism)
[ VR addr, HR addr, MH addr, Sequence, c/o address, Accepted or
Refused, HR/VR data]
HR/VR data includes tunnel specific and service accept info that is
also used to generate VR -> MH packet
8) HR -> SH
- Nothing special ( SH doesn't know the difference )
- Ping responses on behalf of MH if MH is reachable (optional)
9) SH -> HR
- Nothing special ( doesn't know the difference )
Expiration Date March 1994 [Page 6]
- 7 -
10) SH -> MH
- Nothing special ( doesn't know the difference )
4 Element Functions
The functions that each element must perform are indicated below.
SH
- Nothing new
HR
- Authenticate MH
- Advertises direct network layer reachability for MHs associated
(served) with the HR
- Encapsulate packets
- Maintain location of MHs
- Processes tunnel control messages generated by VR intended for
HR. Normal tunnel control handled by tunnel protocol.
MH
- Request and receive c/o address
- Provide authentication information to VR for HR
- Provide permanent address to VR
- Provide normal processing of data packets
VR
- Provide c/o address
- Keep track of visiting MH
Expiration Date March 1994 [Page 7]
- 8 -
- De-encapsulation of messages.
- Provide error notification to the HR if necessary.
- Return packets to HR after MH moved.
5 Registration and Location Update
Registration and Location Update is initiated by a MH (MH-controlled)
and is executed each time the MH wants to change its association with
VRs (acquire a new VR and dissolve an association with an old VR). It
is also executed periodically (timer driven) to refresh information.
The VR can refuse reregistration for local reasons such as over
utilization.
In this approach the VR informs the HR of the MH's location. The VR
can not register a MH without the MHs authentication information.
This is done indirectly through the VR. In order to update the HR
the following must occur
1. The VR agrees to serve the MH
2. The HR agrees to that VR can serve MH
3. The HR agrees to serve MH
Therefore the following sequences can occur:
1st possible sequence:
- MH sends a message to VR with MH-HR authentication info
- VR informs MH of refusal to service MH
Failure at 1).
2nd possible sequence:
Expiration Date March 1994 [Page 8]
- 9 -
- MH sends a message to VR with MH-HR authentication info
- VR agrees to service MH
- VR sends message to HR with MH authentication info
- HR informs VR of refusal to use VR's service
- VR informs MH of HR's refusal to use VR's service
Failure at 2).
3rd possible sequence:
- MH sends a message to VR with MH-HR authentication info
- VR agrees to service MH
- VR sends message to HR with MH authentication info
- HR informs VR of refusal to serve MH
- VR informs MH of HRs refusal to serve MH
Failure at 3).
4th possible sequence:
- MH sends a message to VR with MH-HR authentication info
- VR agrees to service MH
- VR sends message to HR with MH authentication info
- HR informs VR of willingness to serve VR and MH
- VR informs MH of willingness to serve
Success.
The Registration and Location Update protocol is implemented over
UDP.
Expiration Date March 1994 [Page 9]
- 10 -
6 Tunneling
Tunneling mechanism could be the same as used elsewhere in the
Internet. (i.e. mbone) There are no special requirements for
tunnelling, so any tunnelling scheme will do the job but only one
scheme should be adopted.
7 Security
Privacy
- Privacy of data can be achieved by encryption at the
application level.
- Privacy of location is ensure by routing through HR
Authentication
- Authentication of the MH doesn't require trusting third
parties. The only entities that have knowledge of the
authentication keys are the MH and it's HR.
8 Draft of Management Information
Manageability
- Few elements - constrained elements should be easier to manage.
- Well defined flows should allow easier tracking of information
- Common tunneling mechanism should make management easier.
Management Information Bases
MH MIB
Expiration Date March 1994 [Page 10]
- 11 -
- Available VR c/o addrs
- Sequence of previous VRs c/o addrs
- Basis for termination
- Duration of attachment
- VRs that refused service
- Basis for refusal
VR MIB
- MHs being served
- Associated HRs
- Sequence of MHs previously served
- Associated HRs
- Basis for termination
- Duration of attachment
- MHs refused service
- Basis for refusal
- List of MHs willing to serve (optional - default is all)
- Statistics of packets returned to HR
HR MIB
- VRs serving MH
- present VR
- previous VRs
Expiration Date March 1994 [Page 11]
- 12 -
- Refused MHs
- authentication
- unacceptable VR
- MH user profile
- entities that may know MH location
- Acceptable VRs
SH MIB
- Nothing new
9 Pseudo-code for Colocated HR/VR
The following pseudocode describes handling packets by a colocated
HR/VR. Suppression of packet looping due to transients or stale
information is always done at the HR. Looping is suppressed (by
dropping packet) only when the HR can't make any further progress (it
has the same COA as the previous one in the loop).
VR in absence of the ability to deliver locally, sends packet to HR
associated with the destination address.
The pseudo code uses the following abbreviations:
- encap-src-addr -- source address in the outer header
- encap-dst-addr -- destination address in the outer header
- src-addr -- source address in the inner header
- dst-addr -- destination address in the inner header
- COA(addr) returns Care of Address associated with addr
Expiration Date March 1994 [Page 12]
- 13 -
if packet destined to HR/VR { /* acting as either VR or T-HR */
if encapsulation { /* received data packet*/
strip encapsulation;
if local delivery possible /* encapsulator has correct info */
do local delivery;
else {
swap(dst-addr, encap-dst-addr); /* send back to HR */
submit to normal forwarding;
}
}
else { /* SMIP control packets follow this path */
if packet is a SMIP control packet
perform_SMIP_processing(packet);
else
submit for normal local processing;
}
}
else {
if dst-addr != HR's client /* acting as a router */
submit to normal forwarding;
else { /* acting as HR */
if encapsulation { /* packet went at least once through HR */
swap(dst-addr, encap-dst-addr);
if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr {
encap-src-addr = encap-dst-addr = COA(dst-addr);
submit to normal forwarding;
}
else
discard the packet;
}
else { /* packet came from the source, just re-address it */
if (COA(dst-addr) != NULL) {
encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else { /* no forwarding information available */
if local subnet delivery is possible
submit to normal forwarding;
else
discard the packet;
}
}
}
}
Expiration Date March 1994 [Page 13]
- 14 -
/*
* The following pseudo code describe processing of SMIP control
* packets by VR/HR
*/
perform_SMIP_processing(packet)
{
if MH Hello packet {
if VR or T-HR capable
if MH already registered
if MH IP addr already register
if LinkLayer (registered MH IP addr) = LinkLayer (new MH IP addr)
if acting as T-HR for MH
if MH authenticates
convert to VR confirm
set confirm bit
dst addr = MH addr
src addr = T-HR addr
submit to normal forwarding
else /* failed auth at T-HR */
covert to VR confirm /* confirmation refuse */
clear confirm bit
dst addr = MH addr
src addr = T-HR addr
submit to normal forwarding
note MH addr and failed authentication
else /* acting as VR for MH */
convert MH Hello into Location Update
dst addr = HR addr
src addr = VR addr
submit to normal forwarding
else /* Different Link Layer Address for MH IP addr /*
note as security suspicious
else /* MH not registered */
temporarily register MH (MH addr, HR addr, Sequence)
convert MH Hello into Location Update
dst addr = HR addr
src addr = VR addr
submit to normal forwarding
else /* Not VR so should not receive MH Hello packet */
drop packet /* Not beaconing so no need to send error message */
}
else {
if Loc Update Req packet
if acting as a HR or T-HR
Expiration Date March 1994 [Page 14]
- 15 -
if MH authenticates
convert Loc Update Req to Loc Update Confirm
auth key = MH public key
set confirm bit
dst addr = VR addr
src addr = HR add
submit to normal forwarding
register MH at VR
else
convert Loc Update Req to Loc Update Confirm
clear confirm bit
dst addr = HR addr
src addr = VR addr
submit to normal forwarding
note MH addr and failed authentication
else
drop packet /* Not an HR */
else {
if Loc Update Conf packet
if confirm bit set
convert Loc Update Conf to VR confirm
dst addr = MH addr
src addr = VR addr
submit to normal forwarding
convert temp registration to permenant registration
save public authentication key
else /* authentication failed */
convert Loc Update Conf to VR confirm
dst addr = MH addr
src addr = VR addr
submit to normal forwarding
eliminate temp registration
make note of failed authentication
else /* not a VR */
drop packet
}
}
}
Expiration Date March 1994 [Page 15]
- 16 -
10 Acknowledgment
We would like to express our thanks to Kannan Alagappan (DEC), and
Steve Deering (XEROX) for their review and constructive comments.
Appendix A
A.1 Future Enhancements and Associated Issues
We describe possible enhancements that can be added to the base
proposal. The enhancements can be added in an incremental fashion.
A.1.1 Cascading of Systems
In order to cascade systems a VR needs to have some HR functionality.
As indicated earlier a VR and HR can be colocated. A VR functioning
similar to HR is called a T-HR. A T-HR is slightly different than a
HR. For example, unlike the HR, a T-HR does not advertise direct
network layer reachability to MHs served by the T-HR.
The following sequence of events illustrate how cascading can occur
- The MH request VR service
- The VR with T-HR capability provides the HR with the standard
information and informs the HR of it's T-HR capability.
- The HR agrees to allow the VR to serve the MH and also passed a
public authentication key to the VR.
- The VR lets the MH know that the attachment is successful and
the VR is T-HR capable.
- When the MH moves to a new VR it tells the new VR of the T-HR
location and passes an authentication key that the T-HR uses to
Expiration Date March 1994 [Page 16]
- 17 -
authenticate it. As a fall-back position the new VR can always
go to the HR.
- The T-HR agrees to serve as the HR and the new VR acts as if
were part of the baseline system.
This would result in the following new data flow:
SH==>MH: SH->HR->T-HR->VR->MH
PSEUDO CODE FOR CASCADING OF SYSTEMS IN COLOCATED HR/VR
if packet destined to HR/VR { /* acting as either VR or T-HR */
if encapsulation { /* received data packet*/
strip encapsulation;
if local delivery possible /* encapsulator has correct info */
do local delivery;
else { /* packet already traversed through HR */
/*
* Acting as T-HR and have non-null COA
*/
if HR/VR is T-HR capable && dst-addr == T-HR's client && COA(dst-addr)
!= NULL {
encap-dst-addr = COA(dst-addr);
submit to normal forwarding;
}
else { /* encapsulator has stale info, send to HR */
if encap-src-addr != encap-dst-addr { /* packet came from T-HR */
swap(encap-src-addr, encap-dst-addr);
}
swap(dst-addr, encap-dst-addr); /* send back to HR */
submit to normal forwarding;
}
}
}
else { /* SMIP control packets follow this path */
if packet is a SMIP control packet
perform SMIP processing;
else
submit for normal local processing;
}
}
else {
if dst-addr != HR's client /* acting as a router */
Expiration Date March 1994 [Page 17]
- 18 -
submit to normal forwarding;
else { /* acting as HR */
if encapsulation { /* packet went at least once through HR */
swap(dst-addr, encap-dst-addr);
if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr {
send Location Update information to src-addr;
encap-src-addr = encap-dst-addr = COA(dst-addr);
submit to normal forwarding;
}
else {
if COA(dst-addr) == encap-dst-addr
mark COA(dst-addr) as "suspicious";
discard the packet;
}
else { /* packet came from the source, just re-address it */
if (COA(dst-addr) != NULL) {
send Location Update information to src-addr;
encapsulate with encap-src-addr = encap-dst-addr = COA(dst-addr);
submit to normal forwarding;
}
else { /* no forwarding information available */
if local subnet delivery is possible
submit to normal forwarding;
else
discard the packet;
}
}
}
}
A.1.2 Elimination of Triangular Routing
The elimination of Triangular Routing creates a security problem
without an infrastructure that provides a trusted third party to
handle the processing of authentication keys.
Triangular routing may not be as big a problem as some think.
Triangular routing is relatively efficient in the following cases
Expiration Date March 1994 [Page 18]
- 19 -
- The SH is close to the HR while MH is not.
- The MH is close to the HR while SH is not
- The HR is between the SH and the MH.
Both the first and the second cases may be reasonable assumptions
while the third case is random.
Possible solution:
- Allow MH and/or HR to send Location Update Request messages to
MH's peer.
COLOCATED HR/VR PSEUDO CODE FOR ELIMINATING TRIANGULAR ROUTING
WITHOUT CASCADING
if packet destined to HR/VR { /* acting as either VR */
if encapsulation { /* received data packet*/
strip encapsulation;
if local delivery possible /* encapsulator has correct info */
do local delivery;
else {
swap(dst-addr, encap-dst-addr);
submit to normal forwarding;
}
}
else { /* SMIP control packets follow this path */
if packet is a SMIP control packet
perform SMIP processing;
else
submit for normal local processing;
}
}
else {
if dst-addr != HR's client /* acting as a router */
submit to normal forwarding;
else { /* acting as HR */
if encapsulation {
swap(dst-addr, encap-dst-addr);
if encap-src-addr == src-addr { /* packet didn't traverse through HR */
Expiration Date March 1994 [Page 19]
- 20 -
if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */
mark FA(dst-addr) as "suspicious";
discard the packet;
}
else { /* src has stale info */
if FA(dst-addr) != NULL {
send Location Update information to src-addr;
encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else
discard the packet;
}
}
else { /* packet went at least once through HR */
if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr {
send Location Update information to src-addr;
encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else {
if FA(dst-addr) == encap-dst-addr
mark FA(dst-addr) as "suspicious";
discard the packet;
}
}
}
else { /* packet came from the source, just re-address it */
if (FA(dst-addr) != NULL) {
send Location Update information to src-addr;
encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else { /* no forwarding information available */
if local subnet delivery is possible
submit to normal forwarding;
else
discard the packet;
}
}
}
}
Expiration Date March 1994 [Page 20]
- 21 -
A.1.3 Combined Elimination of Triangular Routing and Cascading of
Systems
PSEUDO CODE FOR ELIMINATION OF TRIANGULAR ROUTING AND CASCADING OF
SYSTEMS IN COLOCATED HR/VR
if packet destined to HR/VR { /* acting as either VR or T-HR */
if encapsulation { /* received data packet*/
strip encapsulation;
if local delivery possible /* encapsulator has correct info */
do local delivery;
else {
if encap-src-addr == src-addr { /* packet didn't traverse through HR */
/*
* Acting as T-HR and have non-null FA
*/
if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr)
!= NULL {
encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else { /* encasulator has stale info, send to HR */
swap(dst-addr, encap-dst-addr);
submit to normal forwarding;
}
}
else { /* packet already traversed through HR */
/*
* Acting as T-HR and have non-null FA
*/
if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr)
!= NULL {
encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else { /* encasulator has stale info, send to HR */
if encap-src-addr != encap-dst-addr { /* packet came from T-HR */
swap(encap-src-addr, encap-dst-addr);
}
swap(dst-addr, encap-dst-addr); /* send back to HR */
submit to normal forwarding;
}
}
}
Expiration Date March 1994 [Page 21]
- 22 -
}
else { /* SMIP control packets follow this path */
if packet is a SMIP control packet
perform SMIP processing;
else
submit for normal local processing;
}
}
else {
if dst-addr != HR's client /* acting as a router */
submit to normal forwarding;
else { /* acting as HR */
if encapsulation {
swap(dst-addr, encap-dst-addr);
if encap-src-addr == src-addr { /* packet didn't traverse through HR */
if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */
mark FA(dst-addr) as "suspicious";
discard the packet;
}
else { /* src has stale info */
if FA(dst-addr) != NULL {
send Location Update information to src-addr;
encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else
discard the packet;
}
}
else { /* packet went at least once through HR */
if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr {
send Location Update information to src-addr;
encap-src-addr = encap-dst-addr = FA(dst-addr);
submit to normal forwarding;
}
else
if FA(dst-addr) == encap-dst-addr
mark FA(dst-addr) as "suspicious";
discard the packet;
}
}
else { /* packet came from the source, just re-address it */
if (FA(dst-addr) != NULL) {
send Location Update information to src-addr;
encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
Expiration Date March 1994 [Page 22]
- 23 -
submit to normal forwarding;
}
else { /* no forwarding information available */
if local subnet delivery is possible
submit to normal forwarding;
else
discard the packet;
}
}
}
}
A.1.4 Multicasting
The HR or a T-HR can be used to aid in multicasting of packets to and
from the MH.
A.1.5 Off-line Mobility
Off-line Mobility is an important problem that is unlikely to be
solved at the network layer alone.
References
[1] Carlberg, K., "A Routing Architecture That Supports Mobile End
Systems", Proceedings of IEEE MILCOM, October 1992
[2] Cohen, D., Postel, J., Rom, R., "IP Addressing and Routing in a
Local Wireless Network", INFOCOM 1992, pp. 5A.3.1--5A.3.7
[3] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. "IP-Based
protocols for mobile internetworking", Proceedings of SIGCOMM'91,
ACM, September, 1991, pp. 235--245.
[4] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro, "A Network
Architecture Providing Host Migration Transparency", Proceedings of
SIGCOMM'91, ACM, September, 1991, pp. 209-220
Expiration Date March 1994 [Page 23]
- 24 -
[5] Hiromi Wada, Tatsuya Ohnishi, and Brian Marsh, "Packet Forwarding
for Mobile Hosts", work in progress
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
John Penners
U S WEST Advanced Technologies
4001 Discovery Drive
Boulder, CO 80303
Phone:(303) 541-6106
email: jpenners@atqm.advtech.uswest.com
Yakov Rekhter
T.J. Watson Research Center IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
email: yakov@watson.ibm.com
Expiration Date March 1994 [Page 24]